Network servers store and provide access to client data using various mechanisms, including mechanisms generally based on the concept of a redirector, in which an application program's file-related requests are redirected to an appropriate server. The server receives each request, and performs the requested file operation, that is, as long as no errors, access right violations or other problems occurred. The server then returns a success status along with any corresponding data, such as a file handle for a create/open request, or file data for a read request, which the application program receives in response to its request.
Because computer users are not always connected to their network file server or servers, various client-side caching mechanisms have been developed that allow offline access to local file copies when the network version of the file is otherwise unavailable, such as due to a network outage or intentional disconnection. One such caching mechanism is referred to as a briefcase, in which a user manages a local file cache by dragging files to and from a displayed briefcase, essentially manually deciding what files are cached, when they are cached, and resolving any merge (conflicting file version) issues. As can be readily appreciated, the briefcase mechanism requires a significant amount of user interaction, making it relatively inconvenient for users. Moreover, the briefcase mechanism has its own namespace that is independent of the file system namespace, e.g., a filename can exist in both the briefcase namespace and the file system namespace, or in one but not the other. Applications do not directly or transparently benefit from the briefcase mechanism, because the briefcase is a shell program, and is not part of the operating system and/or the file system that application programs rely on to perform file-related operations.
A recent improvement in client-side caching is described in U.S. patent application Ser. No. 09/134,720, which is generally directed towards a persistent client-side cache of files. With this improvement, a network client can access a locally-cached copy of a file using the same filename and with the same namespace as when the client is connected to the network. Automatic caching is provided, (although manual configuration is still possible), thereby reducing much of the need for user interaction. Further, in this improvement, much of the client-side caching technology is built into the CIFS (Common Internet File System) redirector, which uses the CIFS remote file-access protocol, a published extension to the well-known SMB (server message block) protocol. Because the caching is handled in a redirector, application programs transparently benefit from the cache. For example, when a user is disconnected from the network, requested file operations may be automatically redirected to the cached copy of the file instead of the server.
While such client-side caching technology thus provides many benefits, essentially by providing access to needed files when disconnected from the network or when the network is down, there are still a number of drawbacks to current client-side caching mechanisms. One such drawback is that existing caching technology is tightly integrated with the CIFS redirector. Transparent client-side caching is thus unavailable for other server types having other protocols, such as WebDAV-based (or simply DAV, Distributed Authoring and Versioning), and NFS-based (Network File System) servers/protocols. Adding similar caching technology to each redirector would require modification of the various redirector components, which would be undesirable if not impractical, particularly with third party redirector drivers.
In sum, what is needed is a method and system that are protocol-independent with respect to client-side file caching, to thereby provide a uniform offline experience for users across server types, yet substantially without requiring changes to existing networking components. The method and system should be transparent to users and existing applications, and overcome other drawbacks associated with current client-side caching.